Web conferencing has become very popular in recent years. Often, web conferences where participants may view and interact with documents through user interfaces are accompanied with a phone conference. Typically, in order to participate in a web conference, a user is required to connect to the audio components of the conference separately from the web component of the conference. In such cases, the web conference is conducted over an Internet protocol (IP)/virtual private network (VPN) connection using packetized transport and the audio part of the conference is carried over, for example, a public switched telephone network (PSTN). The web conference and the audio portion of the conference, thus, occur at the same time but are not tightly coupled. More specifically, the two services are provided by distinct and separate mechanisms.
The audio conferencing component is typically accomplished by either a “dial-in” or “dial-out” call flow scenario. The “dial-in” methodology requires a customer to call a predefined number and supply information, such as an access code, that is associated with the meeting in order to join the audio part of the conference. The “dial-in” case is typically initiated manually by the user, and requires inputting an access code via a Dual Tone Multi Frequency (DTMF) signal. The “dial-out” methodology, on the other hand, requires a customer to supply their telephone number via a client interface, such as an application, web site, etc. that the conferencing system would use to call the customer. Typically there is no account code information exchanged in the call signaling or bearer (i.e. DTMF) in a dial-out system. Both the “dial-in” and “dial-out” call flow scenarios, as currently used, however, require the customer to separately access the web and audio components of the web conference which makes it inconvenient for the web conference participants.
It is with these concerns and issues in mind, among others, that aspects of the present invention were conceived and developed.